1. Technical Field
This disclosure concerns a system and method for decommissioning legacy applications by migrating functionality of legacy applications to new platforms and architectures. In particular, this disclosure relates to an efficient and non-invasive way to decommission legacy applications using a phased migration approach.
2. Background Information
A strong demand exists for a system and method to decommission legacy applications in the course of migrating legacy applications to new platforms and architectures. When an organization initiates the decommissioning of a legacy application by migrating functionality to a new platform or architecture, organizations spend a great deal of time and money recreating the functionality of legacy applications from scratch. Often, system integrators desire to reuse existing assets of a legacy application targeted for decommissioning (e.g., legacy applications, processes, and software components) by simply providing a new interface or platform in which to interact with these assets. One such example includes migrating legacy applications to web services in a Service Oriented Architecture (SOA). Unfortunately, developers have identified only a limited number of ways to migrate legacy applications to new platforms and architectures without giving rise to lengthy project schedules and excessive budgets, often forcing companies to reengineer systems and applications from scratch.
Developers often use legacy application migration approaches that do not allow for the phased migration of functionality. Migration approaches that impose a non-phased approach take longer to complete, increase the complexity of testing, and impose a burden on users to adapt to an entire suite of migrated functionality all at once. Even phased migration approaches can be plagued with inefficiencies. For example, one phased migration approach actually expose users to two disparate systems (e.g., the legacy application and the new migration) during the migration until developers complete the entire migration, and force users to interact with the two disparate systems through separate interfaces.
Legacy applications often incorporate Graphical User Interface (GUI) APplications (GAPs) implemented in a closed and monolithic manner. System integrators find migrating existing GAPs a particularly difficult technical challenge, especially for closed and monolithic GAPs because GAPs do not interoperate (e.g., exchange information) with other systems. Because closed and monolithic GAPs do not interoperate with other systems, phased migrations present extremely technical challenges. Given the complexity of GAPs and the cost to efficiently and non-invasively make GAPs interoperable, presents one of the fundamental technical problems of migrating legacy applications.
While newer technology such as web services can provide flexible functionality, organizations have invested heavily in legacy GAPs that developers consider difficult to add to an existing framework of web services and modify to enable interoperability, because of brittle legacy architectures, poor documentation, significant programming effort, and subsequently, the large cost of such projects. Great difficulties and enormous expenses associated with migrating legacy applications into integrated (interoperable) applications exist. Beyond migrating legacy applications into integrated applications components, system integrators and applications programmers must define protocols and implement functionality required to enable information exchanges between the components of integrated applications, which may include GAPs and web services.
Organizations tend to use legacy GAPs as long as possible in business operations, primarily to realize the return on investment for the legacy GAPs. However, system integrators consider the vast majority of GAPs encountered as closed and monolithic and prefer to use legacy GAPs as long as possible to avoid the burden of re-writing the functionality from scratch because of the difficulty of enabling GAPs to interoperate. Most GAPs do not expose programming interfaces or data in known formats. Thus, while system integrators desire to incrementally migrate GAPs components into integrated applications, often the original implementation of a GAP makes migration without re-writing logic impossible.
Further exacerbating the problem is that organizations often do not have access to the source code of third-party GAPs, which prevents organizations from migrating third-party GAPs to new platforms and architectures. In such instances, developers must locate old and often inaccurate requirements documents, observe the third-party GAPs during user sessions and write functionality from scratch. The inability to review legacy source code forces developers to employ extensive testing, but does not ensure that all the developer has captured all the third-party GAPs functionality correctly.
The extraordinary technical challenges associated with decommissioning a legacy application and migrating legacy applications to new platforms and architectures include implementing controlled phased migrations that allow organizations to introduce migrated functionality in manageable portions over time. The technical challenges also include decommissioning and migrating third-party GAPs without the ability to review the legacy source code of the third-party GAPs.
A need has long existed for a system and method that migrates legacy applications to new platforms and architectures in a phased migration approach efficiently and non-invasively.